Stability in Weak Memory Models With Proofs

Concurrent programs running on weak memory models exhibit relaxed behaviours, making them hard to understand and to debug. We examine how to constrain the behaviour of such programs via synchronisation to ensure what we call their stability, i.e. that they behave as if they were running on a stronger model than the actual one, for example Sequential Consistency (SC). First, we define sufficient conditions ensuring stability to a program, and show that Power’s locks and readmodify-write primitives meet them. Second, we minimise the amount of required synchronisation by characterising which parts of a given execution should be synchronised. Third, we characterise the programs stable from a weak architecture to SC. Finally, we present the offence tool implementing our approach, by placing either lock-based or lock-free synchronisation in a x86 or Power program to ensure its stability. Concurrent programs running on modern multiprocessors exhibit subtle behaviours, making them hard to understand and to debug: modern architectures (e.g. x86 or Power) provide weak memory models, allowing optimisations such as instruction reordering, store buffering or write atomicity relaxation [2]. Thus an execution of a program may not be an interleaving of its instructions, as it would be on a Sequentially Consistent (SC) architecture [17]. Hence standard analyses for concurrent programs might be unsound, as noted by M. Rinard in [21]. There exist a few memory model aware verification tools [11, 15, 20, 26], but they often focus on one model at a time, or cannot handle the write atomicity relaxation exhibited for example by Power: generality remains a challenge. Fortunately, we can force a program running on a weak architecture to behave as if it were running on a stronger one (e.g. SC) by using synchronisation primitives. Hence, as observed by S. Burckhart and M. Musuvathi in [12], “we can sensibly verify the relaxed executions [. . . ] by solving the following two verification problems separately: 1. Use standard verification methodology for concurrent programs to show that the [SC] executions [. . . ] are correct. 2. Use specialized methodology for memory model safety verification [. . . ]”. Here, memory model safety means checking that the executions of a program, although running on a weak architecture, are actually SC. To apply standard verification techniques to concurrent programs running on weak memory models, we thus first need to ensure that our programs have a SC behaviour. S. Burckhart and M. Musuvathi focus in [12] on memory model safety for TSO [24]. We generalise their idea to a wider class of models (the one defined in [5], and recalled in Sec. 1): we examine how to force a program running on a weak architecture A1 to behave as if running on a stronger one A2, a property that we call stability from A1 to A2. To ensure stability to a program, we examine the problem of placing lockbased or lock-free synchronisation primitives in a program. We call synchronisation mapping an insertion of synchronisation primitives (either barriers (or fences), read-modify-writes, or locks) in a program. We study whether a given synchronisation mapping ensures stability to a program running on a weak memory model, e.g. that we placed enough primitives in the code to ensure that it only has SC executions. D. Shasha and M. Snir proposed in [23] the delay set analysis to insert barriers in a program, but their work does not provide any semantics for weak memory models. Hence questions remain w .r .t . the adequacy of their method in the context of such models. On the contrary, locks allow the programmer to ignore the details of the memory model, thanks to the data race free guarantee (DRF guarantee) proposed in [3] by S. Adve and M. Hill. Yet, from a compilation point of view, locks are costly. As noted by S. Adve and H.-J. Boehm in [4], “[o]n hardware that relaxes write atomicity [. . . , e.g. Power], it is often unclear that more efficient mappings (than the use of locks) are possible; even the fully fenced implementation may not be sequentially consistent.” Hence not only do we need to examine the soundness of our synchronisation mappings (i .e. that they actually ensure stability to a given program), but also their cost. We present here several new contributions: 1. We define in Sec. 2 sufficient conditions on synchronisation to ensure stability to a program. As an illustration, we provide in Sec. 3 semantics to the locks and read-modify-writes (rmw) of the Power architecture [1] (i .e. to the lwarx and stwcx. instructions) and show in Coq that they meet these conditions. 2. We propose along the way several synchronisation mappings, which we prove in Coq to enforce a SC behaviour to an x86 or Power program. 3. We optimise these mappings by generalising in Sec. 4 the approach of [23] to weak memory models and both lock-based and lock-free synchronisation, and characterise in Coq the executions stable from a weak architecture to SC. 4. We describe in Sec. 5 our new offence tool, which places either lock-based or lock-free synchronisation in a x86 or Power assembly program to ensure its stability, following the aforementionned characterisation. We detail how we used offence to test and measure the cost of our synchronisation mappings. We formalised all our results in Coq. The Coq development, the documentation and sources of offence and all the experimental details can be found online.